feat: Add support for auto-merge and squash options in merge requests#235
feat: Add support for auto-merge and squash options in merge requests#235kriakiku wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: 1b2e758 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughThis pull request introduces three new optional GitLab CI inputs for controlling merge request auto-merge and squash behavior: Changes
Sequence Diagram(s)sequenceDiagram
participant Input as GitHub Actions<br/>Inputs
participant Main as src/main.ts
participant Utils as src/utils.ts
participant Run as src/run.ts
participant GitLab as GitLab API
Input->>Main: Provide CI inputs
Main->>Utils: getOptionalBooleanInput()
Utils-->>Main: Parse boolean values
Main->>Run: Call runVersion() with<br/>merge options
Run->>GitLab: Create/Edit Merge Request
GitLab-->>Run: Return MergeRequestSchema
Run->>Run: Compare current vs desired<br/>merge options
alt Options differ
Run->>GitLab: Accept MergeRequest<br/>with AcceptOptions
GitLab-->>Run: Updated merge request
end
Run-->>Main: Completion status
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
README.md (1)
32-34: Consider documenting the behavioral caveat.Worth noting that
INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS=trueresults in GitLab auto-merging the MR when the pipeline succeeds (i.e., it will be merged without further user action), since the implementation uses the "accept" API. Users who only want to flip the checkbox state may be surprised.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` around lines 32 - 34, Add a note to the README explaining that setting INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS=true will trigger GitLab to accept (auto-merge) the merge request when the pipeline succeeds (using the "accept" API), meaning the MR will be merged automatically rather than merely toggling a UI checkbox; reference the INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS variable name and mention the accept API behavior so users who only want to change the checkbox state are warned.src/run.ts (2)
338-343: Settingsquashon edit but notsquashCommitMessage.
mergeRequestOptionspersists thesquashflag on the MR via edit, butsquashCommitMessageis only applied through theacceptpath. If users want the squash commit message pre-populated on the MR (visible in the GitLab UI before merging), consider including it inEditMergeRequestOptionstoo, which also avoids relying on the accept endpoint for this setting.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/run.ts` around lines 338 - 343, mergeRequestOptions currently sets squash but never includes squashCommitMessage, so the MR edit won't pre-populate the squash commit message in the GitLab UI; update the code that builds EditMergeRequestOptions (the mergeRequestOptions object) to add squashCommitMessage when available (the same source/value used in the accept path) so EditMergeRequestOptions includes both squash and squashCommitMessage, ensuring the MR is edited to contain the commit message prior to accept.
337-343: UseExpandedMergeRequestSchemafor more accurate type annotation.
mergeRequestis typed asMergeRequestSchema, but@gitbeaker/core'sMergeRequests.create()andMergeRequests.edit()both returnExpandedMergeRequestSchema. The accessed fields (iid,merge_when_pipeline_succeeds,squash_commit_message) exist on both types, so this compiles, but the expanded type is the actual return type and would be more precise.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/run.ts` around lines 337 - 343, Change the type of the local variable mergeRequest from MergeRequestSchema to ExpandedMergeRequestSchema to match the actual return type of MergeRequests.create() and MergeRequests.edit(); import ExpandedMergeRequestSchema from `@gitbeaker/core` if not already imported and keep the existing mergeRequest usage (fields like iid, merge_when_pipeline_succeeds, squash_commit_message) and the mergeRequestOptions (EditMergeRequestOptions, mrBodyPromise, removeSourceBranch, labels, squash) unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/run.ts`:
- Around line 365-390: The current logic builds acceptRequest and calls
api.MergeRequests.accept which will immediately merge the MR unless
merge_when_pipeline_succeeds=true; change this to only call
api.MergeRequests.accept when mergeWhenPipelineSucceeds === true (and include
that field in acceptRequest), and when mergeWhenPipelineSucceeds is undefined or
false but only squash/squashCommitMessage need updating, call
api.MergeRequests.edit (the MR edit endpoint) to persist
squash_commit_message/squash settings instead of accept; locate the accept flow
(acceptRequest variable, MergeRequests.accept call, and the checks around
mergeWhenPipelineSucceeds, squash, and squashCommitMessage) and split the logic
so accept is used exclusively for the auto-merge-when-pipeline-succeeds case
while edits use MergeRequests.edit for settings-only updates.
---
Nitpick comments:
In `@README.md`:
- Around line 32-34: Add a note to the README explaining that setting
INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS=true will trigger GitLab to accept
(auto-merge) the merge request when the pipeline succeeds (using the "accept"
API), meaning the MR will be merged automatically rather than merely toggling a
UI checkbox; reference the INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS variable name and
mention the accept API behavior so users who only want to change the checkbox
state are warned.
In `@src/run.ts`:
- Around line 338-343: mergeRequestOptions currently sets squash but never
includes squashCommitMessage, so the MR edit won't pre-populate the squash
commit message in the GitLab UI; update the code that builds
EditMergeRequestOptions (the mergeRequestOptions object) to add
squashCommitMessage when available (the same source/value used in the accept
path) so EditMergeRequestOptions includes both squash and squashCommitMessage,
ensuring the MR is edited to contain the commit message prior to accept.
- Around line 337-343: Change the type of the local variable mergeRequest from
MergeRequestSchema to ExpandedMergeRequestSchema to match the actual return type
of MergeRequests.create() and MergeRequests.edit(); import
ExpandedMergeRequestSchema from `@gitbeaker/core` if not already imported and keep
the existing mergeRequest usage (fields like iid, merge_when_pipeline_succeeds,
squash_commit_message) and the mergeRequestOptions (EditMergeRequestOptions,
mrBodyPromise, removeSourceBranch, labels, squash) unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 40357d2b-280c-4928-b6e8-9022c96cf4f6
📒 Files selected for processing (5)
.changeset/gold-rice-cry.mdREADME.mdsrc/main.tssrc/run.tssrc/utils.ts
| const acceptRequest: AcceptMergeRequestOptions = {} | ||
| if ( | ||
| mergeWhenPipelineSucceeds !== undefined && | ||
| mergeRequest.merge_when_pipeline_succeeds !== mergeWhenPipelineSucceeds | ||
| ) { | ||
| acceptRequest.mergeWhenPipelineSucceeds = mergeWhenPipelineSucceeds | ||
| } | ||
| if ( | ||
| squash === true && | ||
| squashCommitMessage !== undefined && | ||
| mergeRequest.squash_commit_message !== squashCommitMessage | ||
| ) { | ||
| acceptRequest.squashCommitMessage = squashCommitMessage | ||
| } | ||
|
|
||
| if (Object.keys(acceptRequest).length > 0) { | ||
| console.log( | ||
| `updating merge request !${mergeRequest.iid} with options:`, | ||
| acceptRequest, | ||
| ) | ||
| await api.MergeRequests.accept( | ||
| context.projectId, | ||
| mergeRequest.iid, | ||
| acceptRequest, | ||
| ) | ||
| } |
There was a problem hiding this comment.
Calling MergeRequests.accept can merge the MR immediately — guard against unintended merges.
GitLab's accept endpoint (PUT /merge_requests/:iid/merge) performs a merge, not a settings update. It only defers to auto-merge when merge_when_pipeline_succeeds=true is sent and there is a pipeline in progress. Otherwise, if the MR is mergeable, it will be merged immediately. This produces at least two problematic scenarios with the current logic:
- User sets only
INPUT_SQUASH_COMMIT_MESSAGE(noINPUT_MERGE_WHEN_PIPELINE_SUCCEEDS).acceptRequestends up as{ squashCommitMessage }, andacceptis invoked → the MR can be merged right now, even though the user only wanted to set a squash commit message. - User explicitly sets
INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS=falsewhile the MR currently has ittrue. The diff check passes,acceptis called withmergeWhenPipelineSucceeds=false→ immediate merge.
Suggested guards:
- Only call
acceptwhenmergeWhenPipelineSucceeds === true(the only case this API was meant to cover here). - When
mergeWhenPipelineSucceeds !== truebutsquash/squashCommitMessagediffer, persist those viaMergeRequests.editinstead (thesquash_commit_messagefield is editable on the MR resource), not viaaccept.
🔒 Proposed guard
- const acceptRequest: AcceptMergeRequestOptions = {}
- if (
- mergeWhenPipelineSucceeds !== undefined &&
- mergeRequest.merge_when_pipeline_succeeds !== mergeWhenPipelineSucceeds
- ) {
- acceptRequest.mergeWhenPipelineSucceeds = mergeWhenPipelineSucceeds
- }
- if (
- squash === true &&
- squashCommitMessage !== undefined &&
- mergeRequest.squash_commit_message !== squashCommitMessage
- ) {
- acceptRequest.squashCommitMessage = squashCommitMessage
- }
-
- if (Object.keys(acceptRequest).length > 0) {
+ // Only invoke accept when explicitly opting into auto-merge; accept will
+ // otherwise merge the MR immediately.
+ if (
+ mergeWhenPipelineSucceeds === true &&
+ mergeRequest.merge_when_pipeline_succeeds !== true
+ ) {
+ const acceptRequest: AcceptMergeRequestOptions = {
+ mergeWhenPipelineSucceeds: true,
+ ...(squash === true && squashCommitMessage !== undefined
+ ? { squashCommitMessage }
+ : {}),
+ }
console.log(
`updating merge request !${mergeRequest.iid} with options:`,
- acceptRequest,
+ acceptRequest,
)
await api.MergeRequests.accept(
context.projectId,
mergeRequest.iid,
acceptRequest,
)
}GitLab API PUT /projects/:id/merge_requests/:merge_request_iid/merge behavior with merge_when_pipeline_succeeds false vs true
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/run.ts` around lines 365 - 390, The current logic builds acceptRequest
and calls api.MergeRequests.accept which will immediately merge the MR unless
merge_when_pipeline_succeeds=true; change this to only call
api.MergeRequests.accept when mergeWhenPipelineSucceeds === true (and include
that field in acceptRequest), and when mergeWhenPipelineSucceeds is undefined or
false but only squash/squashCommitMessage need updating, call
api.MergeRequests.edit (the MR edit endpoint) to persist
squash_commit_message/squash settings instead of accept; locate the accept flow
(acceptRequest variable, MergeRequests.accept call, and the checks around
mergeWhenPipelineSucceeds, squash, and squashCommitMessage) and split the logic
so accept is used exclusively for the auto-merge-when-pipeline-succeeds case
while edits use MergeRequests.edit for settings-only updates.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
Yes, the only way to specify squashCommitMessage and mergeWhenPipelineSucceeds is by calling the Accept endpoint. This may trigger an immediate merge of the request if no additional rules are set up in the repository (such as requiring an approval from someone other than the author). The GitLab API doesn’t allow doing this any other way. Should I update the README to clarify that setting these parameters via the Accept endpoint might result in an immediate merge?
There was a problem hiding this comment.
Should I update the README to clarify that setting these parameters via the Accept endpoint might result in an immediate merge?
Yes, this is a bit confusing to me.
commit: |
There was a problem hiding this comment.
Pull request overview
Adds new optional inputs to control GitLab merge request auto-merge and squash behavior when creating/updating the versioning MR.
Changes:
- Introduces
getOptionalBooleanInputfor optional boolean inputs (supports"true"/"false"and"1"/"0"). - Extends MR creation/update flow to optionally set
squash, and attempts to set auto-merge / squash commit message via the GitLab “accept” API. - Documents the new inputs and adds a changeset entry.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
src/utils.ts |
Adds optional boolean input parsing helper and repositions truthy/falsy constants. |
src/main.ts |
Wires new optional inputs into runVersion options. |
src/run.ts |
Adds MR options (mergeWhenPipelineSucceeds, squash, squashCommitMessage) and calls MergeRequests.accept with derived options. |
README.md |
Documents new INPUT_* variables for auto-merge and squash. |
.changeset/gold-rice-cry.md |
Declares a minor release for the new feature inputs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
Adds three optional inputs to support auto-merge and squash behavior for merge requests:
Why these options are set via accept
This is implemented through the accept API path because GitLab API support for these merge options is handled there, not through a regular merge request update in the same way.
Reference: GitBeaker issue comment
Behavior
INPUT_MERGE_WHEN_PIPELINE_SUCCEEDS
Sets auto-merge on the created merge request (merge when all checks pass).
If not set, no changes are made.
INPUT_SQUASH
Enables or disables squash commits for the merge request.
If not set, no changes are made.
INPUT_SQUASH_COMMIT_MESSAGE
Optional squash commit message used when squash is enabled.
Summary by CodeRabbit
Release Notes
New Features
Documentation